Implement some more checks in ptr_guaranteed_cmp.
#144885
Conversation
Pointers with different residues modulo their least common allocation alignment are never equal. Pointers to the same static allocation are equal if and only if they have the same offset. Pointers to different non-zero-sized static allocations are unequal if both point within their allocation, and not on opposite ends.
|
r? @davidtwco rustbot has assigned @davidtwco. Use |
rustbot
added
S-waiting-on-review
|
Are two different immutable statics required to have distinct addresses? In other words, is the compiler allowed to optimize two immutable statics with identical contents to be stored at the same place? |
|
I don't think it is, but this also restricts people doing their own custom linking shenanigans, so we should have some stable docs to point to before having logic of this sort in const-eval. That sounds like something t-lang should sign off on. |
|
If you just want to fix #144584, please reduce the PR to only affect the case where both pointers are based on the same static. |
Yes, they are required to have distinct addresses (if non-zero-sized). No, the compiler is not allowed to coalesce two immutable statics with the same contents.
This is guaranteed for non-zero-sized statics, in the Reference:
This (non-zero-sized statics not overlapping) has been FCP'd by T-lang here (though not anything about consteval specifically) |
|
r? @RalfJung |
I would prefer to land all of these changes, but if "Pointers to the same static allocation are equal if and only if they have the same offset" is more straightforward to land than the other two, then I can split them into a followup PR. |
| // runtime inequality of pointers to different ones) (see e.g. #73722). | ||
| Some(GlobalAlloc::Function { .. } | GlobalAlloc::VTable(..)) => 2, | ||
| // FIXME: Can these be duplicated (or deduplicated)? | ||
| Some(GlobalAlloc::Memory(..) | GlobalAlloc::TypeId { .. }) => 2, |
There was a problem hiding this comment.
Currently Memory definitely can be deduplicated. TypeId is its own thing that exists mostly to prevent const-eval from comparing it so we should definitely always return 2 there.
There was a problem hiding this comment.
Okay, I'll split and update the comment for TypeId here.
I'll update the comment in the different-AllocId branch to state that Memory can be deduplicated (and Vtable and Function too).
Can Memory be duplicated? That is, should two pointers to the same Memory allocation (at the same offset) compare equal, or be uncomparable?
There was a problem hiding this comment.
Can Memory be duplicated? That is, should two pointers to the same Memory allocation (at the same offset) compare equal, or be uncomparable?
Until we fix #128775, yes that can happen.
`GlobalAlloc::TypeId` exists mostly to prevent consteval from comparing `TypeId`s, so always return 2 for those (whether the pointers are to the same allocation or not). In the different-allocation case, document that `GlobalAlloc::Memory`, `Function`, and `Vtable` can be deduplicated, at least with other allocations of the same kind, so those should return 2.
…with tests/ui/consts/ptr_comparisons.rs
When comparing a pointer with an integer(-valued pointer), if the integer and the pointer have a different residue modulo the pointer's allocation's alignment, they can never be equal. Else, we can't know.
|
Latest push addresses some parts of review comments, moves the test to |
I would have preferred if you didn't extend the scope of the PR after I already did most of my review. Now I'll have to re-review, so back on the queue it goes. |
Co-authored-by: Ralf Jung <[email protected]>
…zero-sized statics
This is a separate commit. If you prefer I can split this into a separate PR. |
Tracking issue for
const_raw_ptr_comparison: #53020This should not affect
is_null, the only usage of this intrinsic on stable.Closes #144584